Pull Request

🤨 Rationale

There is a change to the HTML spec introducing the CloseWatcher API, which affects the way the native dialog element behaves. Recently, Chrome had released their implementation, and it broke our drawer and dialog (see issue #1713, as well as resulting Chromium issue). Though they rolled back their release of that feature (by moving it back to experimental), it will eventually be implemented in Chrome and other browsers in some form. We want to at least guard against leaving the drawer/dialog in a bad state.

Also fixes #1445

👩‍💻 Implementation

The issue is that the cancel event is intentionally not fired in a couple cases where the dialog is dismissed with ESC.

• One such case was when the there is no user interaction (e.g. clicking, scrolling) in the dialog before pressing ESC. Apparently, this is viewed as a mistake and will likely be changed.
• Another case that is more fundamental to the CloseWatcher API is when there are two ESC presses without an intervening user interaction.

I have added a close event handler in both the drawer and dialog that resolves and clears the promise, if there is one still set. This ensures we are not left in a bad state where the drawer/dialog can't be reopened. Note there are still problems:

• the drawer closes without animation (because we rely on the cancel event to trigger the animation)
• the drawer/dialog can be closed with ESC even if prevent-dismiss is set

Depending on the ultimate CloseWatcher specification, we may decide to deprecate the prevent-dismiss option.

OTHER CHANGES:

• Gave the dialog proper focus styling, rather than the default.

🧪 Testing

I added tests for the specific case now being handled, though these won't currently be running against any browser versions that would exhibit the problem behavior.

I did manual testing using a version of Chromium with the CloseWatcher API enabled.

✅ Checklist

• I have updated the project documentation to reflect my changes or determined no changes are needed.